AWS再入門2018 Amazon EC2 Auto Scaling編
Amazon EC2 Auto Scalingを利用すると、需要に合わせてEC2の台数を増減できます。 これにより、コストとパフォーマンスのバランスをとれます。
Auto Scalingは素晴らしい機能ですが、よく理解して利用する必要があります。 Auto Scalingの基本的な内容と、マスターEC2を使ったAuto Scalingの運用方法をご紹介します。
Auto Scalingを構成する要素
Auto Scaling グループ
Auto Scaling グループは、Auto Scalingの管理単位です。 グループを作成する際に、EC2の最小数、最大数、希望する数を指定します。 EC2の最小数と最大数の間で、インスタンス数が増減または維持されます。
ヘルスチェックのタイプ
Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。 インスタンスが正常ではない場合、該当のインスタンスをTerminate（削除）し、新しいインスタンスを起動します。
ヘルスチェックには2つのタイプがあります。 具体的には、EC2タイプとELBタイプです。
EC2タイプ EC2タイプでは、EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に異常と見なされます。 注意しておきたいポイントですが、Auto Scalingで管理されたEC2を停止すると、EC2はTerminateされます。 「EC2のステータスがrunning以外」に該当するためです。
ELBタイプ ELBタイプでは、インスタンスのステータスチェックとELBのヘルスチェックで状態を確認します。 つまり、EC2のステータスがrunning以外の場合、システムステータスがimpairedの場合、ELBのヘルスチェックに失敗した場合のいずれかに該当すると異常とみなされます。 ELBタイプを選ぶ場合、ELBのヘルスチェックに合格するEC2が起動するように設定してください。 合格しない場合、EC2のTerminateと起動が繰り返されることになります。 具体的には、Auto ScalingによりEC2が起動 → ELBのヘルスチェックに失敗 → EC2がTerminate → Auto ScalingによりEC2が起動 → ELBのヘルスチェックに失敗.. の無限ループが発生します。
ELBタイプとDeep Health Checkパターンの併用はしない ELBタイプとDeep Health Checkパターンの併用は避けましょう。 Deep Health Checkに利用するリソース（DBなど）に問題がある場合、ヘルスチェックに失敗します。 EC2に問題がないのにも関わらず、ELBのヘルスチェックに失敗 → EC2がTerminate → Auto ScalingによりEC2が起動 → ELBのヘルスチェックに失敗 ... の無限ループが発生します。
起動設定
Auto Scalingで管理されるEC2は起動設定で指定した条件で、起動します。 起動設定は、Launch Configとも呼ばれます。 AMI ID、インスタンスタイプ、キーペア、セキュリティグループなどを指定します。
スケーリングの必要性や手法を考えよう
Auto Scalingを利用する場合でも、必ずしも自動でEC2の台数を増減させる事はしません。 そもそもスケーリングが必要ない事や、手動でのスケーリングで十分なケースもあります。 スケーリングに関連する代表的なケースを紹介します。
スケーリングはせずインスタンス数の維持に利用する
前述のようにAuto Scalingはヘルスチェックを行い、異常のあったEC2をTerminateし、新しいEC2を起動します。 EC2でハードウェア障害があった場合は、上記の流れで正常なEC2の数が維持されます。 オートヒーリングと呼ばれる手法です。
手動でのスケーリング
EC2がスケーリングする必要性が事前にわかっていることがあります。 例えば、スマホアプリのプッシュ配信やSNSで告知するといったケースです。 手動でスケーリングする場合、Auto Scaling グループのEC2の最小数、最大数、希望する数を調整します。 台数を減らす場合も同様に数を調整します。 手動でのスケーリングで十分なケースも多いです。
EC2の台数を増やすだけでなく、システム全体がスケーリングするようにしましょう。 特にサービス開始時やメディアへの露出時などは、ELBのPre-WarmingやRDSのスケールアップ、CloudFrontでのキャッシュなども検討します。
スケジュールに応じてスケーリング
インスタンス数を増減すべき日付や時間がわかっている事があります。 例えば、お昼休みにアクセスが急増するようなWebサイトでは、12時前にEC2を増加させ13時以降に減らします。 Auto Scalingでは、予定アクションを定義しておく事でそのような要求を実現します。
需要に応じてスケーリング
スケーリングポリシーを定義しておくことで、需要に応じてスケーリング出来ます。 例えば、CloudWatchのCPUUtilizationを監視し90%を超えたら、EC2を増やすといった事が可能です。 スケールイン（EC2を減らす）ポリシーについても定義しておきます。
Auto Scalingは起動設定で指定したAMIから起動する
Auto Scalingを利用する上で必ず抑えておきたいのは、「Auto Scalingで管理されるEC2は起動設定で指定したAMIから起動する」ということです。 Auto Scalingで起動済みのEC2に設定変更を行った場合、そのEC2とAMIに設定の差異が生まれます。 AMIを使って新しく起動するEC2と、起動ずみのEC2に差異が生まれることを意味します。
同様の更新をAMIにも行うか、EC2の起動処理で同様の処理を行うようにします。 EC2の起動処理については、以下のような手法で対応できます。
例として、ユーザーデータを指定するとEC2の起動時にシェルスクリプトをEC2にわたし、OSの更新などの処理を行えます。 具体的には以下のようなシェルスクリプトを実行できます。
#!/bin/bash yum update -y yum install -y httpd24 php56 mysql55-server php56-mysqlnd
Auto Scalingの利用イメージ
マスターとなるEC2を使うAuto Scalingの運用イメージを整理します。 Auto ScalingでELBに登録されたEC2を起動する流れと、EC2とAMIを更新する流れを記載します。 Auto Scalingの利用方法は多岐にわたるので、あくまで1つの方法としてご理解ください。
Auto ScalingでEC2を起動する流れ
AMIを作成する
Auto ScalingでELBに登録されたEC2を起動する流れを記載します。 公式のAMIから、EC2を起動しアプリケーションをセットアップします。 このEC2はマスターとして保持します。利用しない時はstopします。
図では、カスタムAMI1を作成した様子を示します。
起動設定を作成する
Auto Scalingの起動設定を作成します。 AMI ID、インスタンスタイプ、キーペア、セキュリティグループなどを指定します。
Auto Scalingグループを作成する
起動設定を指定する形で、Auto Scalingグループを作成します。 "EC2の希望する数"で指定した数のインスタンスが起動します。 ELBターゲットグループを指定すると、起動したインスタンスはELBに登録されます。 Classic LoadBalancerを利用する場合、ロードバランサーを指定します。
カスタムAMI1から2台のEC2が起動し、ELBに登録された様子を図にします。 Auto Scalingグループで「最小数2、最大数:2、希望する数:2」したケースです。
EC2とAMIを更新する流れ
AMIを作成し、起動設定を作成
ここからは、EC2とAMIを更新する流れを紹介します。 以下の2つが達成できたら、完了です。
- 新しいEC2がカスタムAMI2から起動すること
- 既存のEC2がカスタムAMI2から起動していること
マスターEC2を更新しAMIを作成します。 新しい起動設定を作成し更新したAMIを指定します。 起動設定は編集できないため、新しく作る必要があります。
図は、EC2を更新し、カスタムAMI2と起動設定2を作成した様子を示しています。
新しい起動設定に変更する
Auto Scalingグループで指定する起動設定を変更します。 例では起動設定1から起動設定２に変更しています。 同時にEC2の最大数、希望する数を大きくします。 例では、最大数:2→4、希望する数:2→4に変更しています。
新しい起動設定を利用したEC2が起動する
希望する数:4にあわせる形で、2台のEC2が起動します。 新しいAMIから起動したEC2と古いAMIから起動したEC2が混在した状態になります。
古い起動設定から起動したEC2をデタッチする
古いEC2をAuto Scalingグループからデタッチします。 該当のEC2にクライアントからの通信が発生している場合、通信断が発生する可能性があります。 影響が少なくなるように、ELBの登録解除の遅延を活用します。 新しい接続は登録解除中のEC2に送信されません。 処理中のリクエストについては、指定した時間待つことにより正常に完了する可能性をあげます。 処理中のリクエストを正常完了できる可能性と、登録解除にかかる時間はトレードオフです。
古い起動設定から起動したEC2を削除する
デタッチ時に代わりのインスタンスを起動するか選択できます。 例ではEC2の入れ替えのためにデタッチしたため、代わりのEC2は起動しません。 代わりのEC2を希望しないと、"EC2の希望する数"が減ります。 デタッチしたインスタンスは不要な場合、手動で削除します。
EC2の入れ替え手順の検討
終了ポリシーを使って、EC2を入れ替える方法もあります。 Auto Scalingグループからデタッチする方法は、対象のEC2を明示的にユーザーが選択できる点がメリットです。 デタッチしたインスタンスは手動でTerminateする手間はデメリットとも言えます。
終了ポリシーを使った方法は、Terminateされるインスタンスはポリシーによって自動的に選択されます。 台数の多いAuto Scalingグループを運用する場合は、メリットといえます。 逆にいうと意図しないインスタンスがTerminateされる可能性があるので、ポリシーを理解して使う必要があります。
起動ずみのEC2に変更を加える
起動ずみのEC2に変更を行う場合、マスターEC2にも同様の変更を行い起動設定を入れ替えます。 以下の例では"カスタムAMI3"を作成し、Auto Scalingグループで指定する起動設定を3に変更します。 次回スケーリングが発生した時にはカスタムAMI3からEC2が起動します。 つまり、起動ずみのEC2と新しく起動するEC2で整合性が保たれます。
整合性を保つ事が難しい場合、起動ずみのEC2には一切手を加えない運用も考えられます。
EC2はいつでもTerminateされて大丈夫なように備える
Auto Scaling グループから起動したEC2は、削除されても問題ないようにします。 ヘルスチェックに失敗してTerminateされたり、スケールインによりTerminateされるからです。 Terminateによりアプリケーションログも消失します。 ログを後から参照できるように、CloudWatch Logsを利用してほぼリアルタイムにログを退避したり、fluentdなどによる退避を短い間隔で行います。
おわりに
Auto Scalingの基本的な内容をご紹介しました。 Auto Scalingは柔軟性に富んだサービスです。 様々な活用方法が考えられますが、これからAuto Scalingをご検討のかたは小さく初めてみることをお勧めします。 慣れてきたら、他サービスとの連携や完全自動なスケーリングなどをお試しください。
![[小ネタ] Windows AMIの更新通知の購読をAWS CLIから行う](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-daa54df39308ec469607d6a913b81811/3c36486880ec490db06f2c3f36080c43/amazon-sns)
